1. Field of the Invention
The present invention relates to database software applications. More specifically, the present invention relates to the interworking of desktop applications and databases.
2. Description of Related Art
One common practice in the field of database systems deployment is to build client applications after the database is laid out and its schema or model has been defined.
Database systems primarily consist of three tiers:
Tier 1 (referred to hereafter as xe2x80x9cdatabasexe2x80x9d)xe2x80x94one or more data sources (usually relational databases, but also directory services like LDAP (Lightweight Directory Access Protocol) or object-oriented databases;
Tier 2 (referred to hereafter as xe2x80x9capplication serverxe2x80x9d or xe2x80x9cserverxe2x80x9d)xe2x80x94one or more server applications/systems connecting to the database and providing data to Tier 3; and
Tier 3 (referred to as hereafter as xe2x80x9cclient applicationxe2x80x9d or xe2x80x9cclientxe2x80x9d)xe2x80x94one or more programs providing a front-end to the data provided by the application server.
Object-oriented application servers present the data fetched from the data sources as objects in a high level programming language like Java. For relational database systems, servers usually have to xe2x80x9cmapxe2x80x9d the data from the data sources into objects (transform data sources storing data in tables and fields relationally into an object framework). In the case of object-oriented databases in tier 1 such mapping is not necessary.
Application servers use a so-called xe2x80x9cdatabase modelxe2x80x9d or xe2x80x9cmodelxe2x80x9d to define how the data objects they work with map to the underlying data source. Models consist of xe2x80x9centitiesxe2x80x9d which are descriptions of the data objects. Every entity describes one type of data object. Entities are defined with the help of xe2x80x9cattributesxe2x80x9d and xe2x80x9crelationshipsxe2x80x9d (both attributes and relationships are also referred to as xe2x80x9cpropertiesxe2x80x9d, so every attribute and every relationship is a property). An xe2x80x9cattributexe2x80x9d is a persistent atomic piece of information assigned to a data object (for example a customer""s name or an order number). Every entity has a xe2x80x9cprimary keyxe2x80x9d which is used to identify objects uniquely (usually the primary key is a subset of the attributes of the entity). Relationships define how objects behave and are conditioned in relation to one another (for example, an order can be assigned to exactly one customer (so-called xe2x80x9cto-one relationshipxe2x80x9d) and a customer can have multiple orders (so-called xe2x80x9cto-many relationshipxe2x80x9d)).
Entities in the model can map to one table in the database or to multiple ones (for example, in the case of object inheritance where different variations of an object class are mapped to different tables in the database). In relational databases, relationships are defined with the help of attributes (objects relate to each other if values of specific attributes are identical) which can map to one or multiple fields in the database. The application server can maintain attributes used for primary keys and relationships (referred to as xe2x80x9cforeign keysxe2x80x9d) separately from the data object used to present the data from the data source, so that primary keys and foreign keys do not appear as attributes of the data object itself. The application server then handles filling in the values for these primary and foreign keys when communicating with the database.
On a system level, referring again to the three tiers, due to the inherent independence of these tiers, each client or server is typically programmed/configured to transact with the data store in an independent fashion. In the case of a client, a user interface (UI) that allows users to interact with the data store is usually built as a desktop window application displayed on the client. The UI application is built manually and is based upon a human interpretation of the database model/framework. Based on the model, the human designer would design windows and views that would present the various entities and other data objects in a friendly, easy-to-manipulate manner. Based upon this design, program code for the UI was written/generated and then the application executable compiled. The application is then executed on the client machine and then connects with the server which links the data store together with the client. The client UI is then able to fetch objects from the server and present them to the user for viewing, updating and modification as desired. Once the client UI application is developed, it can be duplicated and distributed to clients having a compatible instruction-set and/or operating system platform. However, where UI applications are needed for clients incompatible with that of the developed application, a new application, and perhaps new design, needs to be programmed, compiled and executed.
With the advent of the Java programming environment, executables could be programmed on one machine an then run on any other platform, whether compatible or not. The primary distribution of Java (a product of Sun Microsystems) applications, such as Java xe2x80x9capplicationsxe2x80x9d, to clients has been via networks such as the Internet through vehicles such as connected WWW (world wide web) browsers. Even with Java, which relieves partially the problem of code incompatibility, a human must still evaluate the framework or schema and design the interface. To reduce the inefficiencies inherent in such deployment of client UIs with their databases, there is a need to automate the building of UIs.
Further, where changes are made to the framework or schema of a data store, applications must then be re-programmed and re-compiled. Often, user interfaces are not made customizable, so that the same user interface would be presented to different users. Unless the UI is customizable and customizable in conformance with the framework/schema, the UI must be redesigned and reprogrammed (even using Java) if the user is to be able to run their desired UI. For instance, an engineer may not be as concerned about a portion of the database concerning financial information. Such a user may desire to have a UI that eliminates such information from his/her view. Thus, there is also a need to both enable customization and allow for changes to schema without the added cost, complexity and time of completely re-implementing the application.
The invention is a method and apparatus for automatically and dynamically generating a user interface for a client based upon a database model. An application server creates a user interface description in accordance with the database model. The description is then distributed to the client, which interprets the description and creates the user interface therefrom. In some embodiments, a user may provide preferences and authentication to the application server which can create a modified description of the user interface.